When creating default values a trait method needs to be called with an
explicit trait name.  `Default::default()` seems redundant.  A free
function on the other hand, when imported directly, seems to be a better
API, as it is just `default()`.  When implementing the trait, a method
is still required.

I wasn't aware items _could_ be fake, so I think having a function
mentioning it could be helpful. Also, I'd need to make this change for
cross-crate intra-doc links anyway, so I figured it's better to make the
refactor separate.

…ts` query

This is to avoid the final conversion from `NodeId` to `HirId`
during call to `Resolver::(clone|into)_outputs`.

Free `default()` forwarding to `Default::default()`

It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance.
Especially so, compared to Haskell, where the same functionality is called `def`.
Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation.
The trait is still there, so if someone wants to be explicit and to say `Default::default()` - it still works, but if imported as `std::default::default;`, then the free function reduces typing and visual noise.

Add comments to `Resolve::get_module`

r? @Manishearth

…def-id, r=petrochenkov

Use `LocalDefId` directly in `Resolver::export_map`

This is to avoid the final conversion from `NodeId` to `HirId`
during call to `(clone|into)_outputs`

This brings down the post-lowering uses of `NodeId` down to 2 calls to convert the `trait_map`.

cc rust-lang#50928

r? @petrochenkov

…an-DPC

Clean up E0646

r? @Dylan-DPC

…Gomez

Add Item::is_fake for rustdoc

I wasn't aware items _could_ be fake, so I think having a function
mentioning it could be helpful. Also, I'd need to make this change for
cross-crate intra-doc links anyway, so I figured it's better to make the
refactor separate.